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Remarks/Arguments 

This paper is filed in response to the Final Office action mailed 14 April 2003 and is filed 
in conjunction with a Request for Continued Examination and a petition and fees for a two 
month extension of time. Assignee again thanks the Examiner for his continued diligent review 
of the claims in the present case, but, respectfully traverses all of the Examiner's rejections, as 
set forth in the Final Office action of 14 April 2003 (hereinafter, the "4 th OA"). In order to move 
this case along, Assignee has amended pending independent claims 1, 1 1, 26, 32, 82, 106, and 
130 to more precisely identify how the user profile information in provided and utilized in the 
present invention. Assignee believes that such additional structure and functional language is 
sufficient to overcome all of the Examiner's outstanding rejections. 

After entry of the foregoing amendments, claims 1, 5-8, 10-12, 16, 19, 21, 22, 24-28, 31- 
34,37-38, 43-45,47-48,53-56, 73-77,81-84, 105-108, 112, 117-121, 126, 128, 130, 131, and 
133-135 remain pending and claims 2-4, 9, 13-15, 17, 18, 20, 23, 29, 30, 35, 36, 39-42, 46, 49- 
52, 57-72, 78-80, 85-104, 109-111, 113-116, 122-125, 127, 129, 132 and 136-141 have been 
cancelled. No new matter has been added to any of the pending claims. 

Objection to the Drawings 

The Examiner has objected to the drawings because of noted informalities. Assignee will 
submit formal drawings when the application has received a notice of allowance. 
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Claim Rejection - 35 U.S.C. S 103 

In the 4 th OA, the Examiner again has rejected claims 1, 1 1, 25, 27, 28, 32-34, 44, 46, 56, 
59, 65, 67-70, 73-74, 130-132 and 136-138 under 35 U.S.C. 103(a) as being unpatentable over 
Becker (USPN 5,878,223) in view of Kramer et al. (USPN 6,327,574). More specifically, in the 
4 th OA, the Examiner has again stated that Becker, in view of Kramer, teaches all of the elements 
set forth in the above listed claims. Assignee appreciates that such rejections were issued prior 
to incorporation of the above amendments and that the Examiner's position vis-a-vis the pending 
claims has most likely changed in light of the present claim amendments. Nonetheless, herein 
the Assignee addresses the various rejections raised by the Examiner in the 4 th OA, and while 
Assignee contends such rejections have been rendered moot by the above claim amendments, 
Assignee nonetheless respectfully traverse all such rejections. In traversing such rejections, 
Assignee again relies upon those arguments set forth in their response to the 3 rd Office Action of 
23 October 2002. In short, Assignee contends that both before and especially after entry of the 
above amendments, the presently pending claims are allowable over Becker in view of Kramer 
for the following reasons. 

First, with respect to claim 1, Assignee contends that this claim is non-obvious over 
Becker in view of Kramer because neither reference, alone or together, sets forth a computer 
readable medium in which fields are included: a) for specifying an identification of a machine; 
b) for specifying an address of the machine; and c) for specifying user-profile information. In 
particular, Assignee contends that in the 4 th OA, the Examiner has not identified where in Becker 
and Kramer each of these elements (i.e., a-c) are taught as being combined. Assignee contends 
that it is the combination of these elements of information in a computer readable medium that 
.enable certain beneficial results to occur, such as the efficient targeting of user's with content, 
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regardless of how they are connected to a network at any given time, and without relying upon 
cookies or other device specific profile information. 

In particular, Assignee contends that Becker simply does not teach combining "fields for 
specifying an identification of a machine," "fields for specifying an address of a machine," and 
"fields for specifying user profile information" in a computer readable medium. Becker teaches 
a "prediction table," which, as asserted previously, Assignee contends does not contain user- 
profile information. However, for sake of argument, even if one were to consider the "prediction 
table" in Becker as providing user-profile information, Assignee contends it still does not 
provide and can not be reasonably interpreted as providing "fields for specifying an 
identification of a machine" or "fields for specifying an address of a machine." Assignee is not 
aware of any identification by the Examiner that the prior art of record provides an address of a 
machine, or even an identification of a machine, as "user-profile" information. Similarly, 
Assignee is not aware of any section in Kramer which provides for the above limitations, 
namely, identifying the machine and an address associated therewith. Since the Examiner has 
not set forth a showing in the prior art to combine, let alone provide fields in a computer readable 
medium for elements a), b) and c), Assignee contends that the Examiner has not established a 
prima facie case of obviousness. As such, notwithstanding the present claim amendments, 
Assignee contends presently pending claim 1 is both novel and non-obvious. 

Further, Assignee has also amended claim 1 to further specify how the user-profile 
information is stored in the computer readable medium. In particular, Assignee has amended 
claim 1 to specify that the user profile information is stored in a "donut" and that the donut 
utilizes a hierarchical attribute value pair data structure ("HAV"). Assignee contends that neither 
"donut" nor "HAV" are terms of art and that the inventors are their own lexicographers, as 
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permitted by the patent laws and regulations. As such, Assignee contends that the Examiner 
should have appreciated that one skilled in the art would have looked to the specification for the 
definitions of HAV and "donut." Such an examination of the specification would have led one 
to appreciate that an HAV includes at least one attribute that is expressed as a value pair data 
structure that is independent of the hierarchical structure and that is also adapted for being shared 
with at least one other donut. Such, definition of HAV has now been expressly included in claim 
1. As such, the Examiner's arguments of "over breadth" are believe to now be rendered moot, as 
claim 1 clearly provides a specific definition of an HAV. Further, Assignee contends that an 
HAV, as defined herein and in the specification, is not covered by the structures set forth in 
Becker or Kramer. 

In particular, an "HAV," as set forth in the amended claim 1, is a "donut" (i.e., a data\ 
structure) wherein at least one value pair data structure (or attribute) in the data structure is J 
independent of the structure and is adapted for being shared with at least one other donut. 
Assignee contend that Becker and Kramer simply do not set forth such a structure because the 
attributes are neither independent, nor are they separately adapted for being shared. 

For example, with respect to Becker, Assignee understands the Examiner's position as 
being that the probabilities in the "prediction tables" are essentially user-profile information. 
Even if one were to adopt such a position, Becker still can not reasonably be interpreted as 
providing that such probabilities are independent and adapted for being shared with other 
prediction tables, because Becker teaches the exactly opposite conclusion. For example, 
Becker's Fig. 5 A provides one example of a simple prediction table wherein each attribute sets 
forth a probability that a specific page (page "b") will be selected after the current page (page 
"a"). It is inherently obvious that the total of all the probabilities of any page being selected after 
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page "a" must equal 100%. As such, the probability that page "b" is selected next inherently is 
dependent upon the change in the probability of any other of the available pages being selected 
next. So, for example, if page "c" was suddenly selected more frequently, then the probability of 
"c" would increase while the probability of "b" would necessarily decrease (assuming the only 
page options available were pages "b" and "c"). Thus, in Becker every attribute in the prediction 
table depends upon every other attribute for its value. An attribute can not be independent unless 
only a single option exists (in which case determining the probability of a next page being 
selected is a futile exercise). 

Further, such dependencies among Becker probabilities impact their adaptability for 
being shared. For example, a probability that page "b" would be selected next from Web Site 
"a" clearly is not relevant when the user is on Web Site "c", because the next page options from 
Web Sites "a" and "c" arguably will be different, if not different, then once again there is no 
need to have a separate prediction table and there is no need to share the prediction value of page 
"b" being selected next with another data structure, because changing "b" invariably must 
change all of the other prediction values in the table. Thus, Becker can not be read as teaching or 
providing for the use of independent probabilities in its prediction tables or the sharing of 
probabilities, because such an interpretation leads to illogical results. 

Thus, using presently pending claim 1 provides that at least one value pair is independent 
of the hierarchical structure and is adapted for being shared with another hierarchical structure. 
In Becker, attributes depend upon the remainder of the hierarchical structure for their definition 
and their value, as such they can not be independent and Becker can not read upon claim 1 . 

Similarly, Assignee contend that Kramer also does not teach a "donut" with an 
independent attribute that may be shared with another "donut." In particular, Kramer teaches a 



21 



Serial No.: 09/409,305 

hierarchy of values which depend upon sub-values in the same hierarchy for their meaning and 
value. For example, Figure 9 of Kramer provides an "illustration of a hierarchical attribute 
vector" for a given user (See Kramer, col. 4, line 13) wherein "each aggregated attribute in this 
vector 904 is associated with a selected plurality of base level attributes." (Col. 22, lines 29 - 
31). Such interdependencies dictate that if one were to modify the value of a given attribute, 
such as "xl," then the value of dependent attributes, such as "al" and "bl," must also change 
because the attributes are not independent. In Kramer, any given attribute depends upon sub- 
attributes in the hierarchy for their meaning and value. As such, in Kramer attributes are not 
independent of the hierarchy and thus are not adapted for being shared with other hierarchies. 

For the foregoing reasons, Assignee respectfully contends that Becker in view of Kramer 
does not read upon each and every element of claim 1 as amended above. Similarly, Assignee 
contends that Becker in view of Savitzky (USPN 6,012,083) also does not read upon the above 
invention claimed in claim 1, pre and/or post entry of the present amendments. 

In particular, in the 4 th OA, the Examiner again rejected claims 1-141 under 35 USC 
103(a) as being unpatentable over Becker in view of Savitzky. In issuing this rejection, the 
Examiner relies upon Savitzky for "teaching a 'feature calculator [that] generates a feature list 
for a transaction by scanning the data element' (See 4 th OA, page, 5, If 8, lines 2-3) and that 
"'additional features can be added at any time to the features calculator's known features' col. 6, 
lines 53-54 to highlight the data is independent of the calculated hierarchy." (See 4 th OA, page 
5, If 8, lines 3-5). As such, the Examiner, again, apparently contends that the "feature calculator" 
in Savitzky relates to user-profile information. Assignee respectfully contends that the feature 
calculator does not relate whatsoever to user-profile information. As shown immediately below, 
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every reference to the "feature calculator" is Savitzky is reproduced. None of these references 
refer, suggest, mention or even discuss user-profile information. These references are: 

Resolver 24 includes an agent array 20, a feature calculator 21, a 
transaction queue 23, a match checker 25, an M act_ on" processor 
27, a handler 29 and an agent registrar 31. (Col. 5, lines 33-36, 
bold added). 

When a transaction is received by resolver, it is first processed by 
feature calculator 21. Feature calculator 21 generates the 
feature list for a transaction by scanning the data element (and 
possibly other elements) of the transaction to come up with a 
feature set. Examples of transaction features are shown in Table 2. 
The feature list is a "cache" of features of the transaction . By 
evaluating all the features once, the transaction data does not have 
to be scanned each time an agent needs to know if the transaction 
has certain characteristics. Of course, if a transaction is modified, 
the transaction might be reprocessed by feature calculator 21 or 
an equivalent process. (Col. 6, lines 37-49, emphasis added) 

Each transaction feature is represented in feature calculator 21 by 
a snippet of code (a C or Perl function, or the like) so that 
additional features can be added at any time to the feature 
calculator's known set of features. For example, if a new graphics 
document format, XYZ, were to be developed after an agency were 
in place, a new feature snippet IS._ XYZ could be sent to the 
resolver (possibly using a transaction directed at a "feature 
installer" agent) for insertion to feature calculator 21. Then, 
when feature calculator 21 scans a transaction's data, if it detects 
the XYZ format, the new snippet of code would give a return value 
of "true" and the feature calculator would add IS_ XYZ to the list 
of features for that transaction. As explained below, since agents 
each carry their own criteria, an agent programmed to act on or 
handle XYZ format documents can be easily installed into agency 
array 20. (Col. 6, lines 51-67, bold added). 

Further, as shown by the underlined portion above, the feature calculator clearly generates a 
feature list. The feature list "is a 'cache' of features of the transaction" (col. 6, lines 42-43) it is 
not a cache of user-profile information. Examples of such transaction features are further shown 
in Table 2 in Savitzky, which is reproduced below: 
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TABLE 2 



Transaction Features 



Feature Description 


is_ 


response* 


This transaction is a response to a request 


is_ 


request* 


This transaction is a request for a document 


is_ 


agent_response* 


This transaction is a response from an agent 






(agents can create transactions) 


is_ 


proxy_ request* 


This transaction is a request from/to a proxy 


is_ 


agent_ request* 


This transaction is a request from/to an agent 


is_ 


text 


This transaction's data is a text document 


is_ 


html 


This transaction's data is an HTML 






format document 


is_ 


image 


This transaction's data is an image 


is_ 


local_ source 


This transaction is from a source within 






the agency 


client_ is_ netscape 


The client dealing with this transaction is a 






Netscape .TM. browser or compatible browser 


is_ 


file_ request 


This transaction is a request for a file 


is_ 


interform 


This transaction is an interform (a document 



which combines a program with a form) 



*These features exist by default for each transaction 
(Col. 7, lines 1-21) 

The above passages clearly show that in Savitzky information about a transaction is 
characterized by scanning the data elements of the transaction to generate a feature list. The 
feature list does not contain the data in the transaction, it contains an identification of the type of 
data provided in the transaction. Such types (as set forth in Table 2) include, for example, 
whether a transaction is a response, whether the transaction's data is formatted in HTML, as an 
image, as a text document, and the like. These transaction types are then used by a resolver to 
match an agent process (for example, an agent process designed to interpret HTML formatted 
data) to the transaction so that the transaction can be completed. Thus, the feature calculator 
generates a feature list that describes the type of transaction that has been requested. It does not 
describe, characterize or profile the underlying data and it does not describe a profile for a user 
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requesting the transaction. Thus, even under a broad interpretation, Savitzky should not be 
considered as teaching or relating to the collection, use, storage or the like of user-profile 
information. 

Apparently, the Examiner in considering Savitzky as teaching user-profile information 
contends that the "feature list" is synonymous with the HAV of the present invention, and that 
the feature list provides features that are independent of the list. In supporting this proposition, 
the Examiner states that, "'additional features can be added at any time to the features 
calculator's known features,' col. 6, lines 53-54 to highlight the data is independent of the 
calculated hierarchy." (4 th OA, pg. 5, f 8, lines 3-5). In response to this characterization of 
Savitzky, Assignee notes that the immediate passage above clearly provides that features are 
"added to the feature calculator and not to the feature list. Thus, even assuming for point of 
argument only that the feature list is comparable to a database, the above passage still does not 
support the Examiner's conclusion that adding features to a features calculator "highlight [that] 
the data is independent of the calculated hierarchy" because the features are not added to the 
feature list. The features are added to the features calculator - the device which generates the 
features list. Thus, for purposes of determining the validity of claim 1, Assignee contends that it 
is irrelevant whether the features calculator may add new features. Claim 1 provides that at least 
one value pair in the HAV is independent, it does not provide that the computer readable 
medium may be accessed by a software application that may be configured with new features. 

Additionally, the preceding passage from Savitzky does not support the Examiner's 
position that in Savitzky the features on a features list are independent of the hierarchy, because 
of the simple fact that a list is not a hierarchy. In particular, Assignee contends that one skilled 
in the art would understand the "list" in Savitzky as being an "an item-by-item series of words or 
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numbers . . . written or printed one after the other" {Webster s II New College Dictionary, 1995, 
pg. 639) or perhaps, at best, a table of information. In contrast, a "hierarchy" is "a ranked or 
graded series" {Websters II, at pg. 522) or "a structure that has a predetermined ordering from 
high to low." (McGraw Hill Computer Desktop Encyclopedia, 9 th Edition, 2001, pg. 423). 
Using common definitions, it is clear that a list is not synonymous with a hierarchy. Presently 
pending claim 1 clearly provides that the user-profile information is specified as a hierarchy. 
Savitzky clearly provides for generating a list. Therefore, Savitzky can not be read upon claim 1 
or any of the other presently pending claims because of the simple fact that a list is not a 
hierarchy. 

Therefore, Assignee contends that Becker in view of Savitzky does not teach each and 
every element of claim 1 because neither reference teaches user-profile information and neither 
teaches providing user-profile information in a hierarchical attribute data structure wherein at 
least one attribute in the structure is independent of the hierarchy and is adapted to being shared 
with another hierarchy. 

With regards to presently pending claims 1 1, 25, 27, 28, 32-34, 44, 56, 73-74, and 130- 
(i.e., after entry of the present claim amendments) Assignee contends that for the above reasons 
each of these claims are also non-obvious and are patentable over Becker in view of Kramer 
and/or in view of Savitzky. 

Additionally, in paragraph 9 of the 4 th OA, the Examiner rejected dependent claims 2, 3, 
12, 13, 18, 19, 21 and 24 under Savitzky (col. 6, lines 55-60) as teaching attributes of a user. 
After entry of the present claim amendments, claims 12, 19, 21, and 24 remain pending. 
Assignee respectfully traverses the Examiner's rejection of these claims based upon the cited 
passage from Savitzky. In particular, Assignee notes that claim 12 essentially provides for 



26 



Serial No.: 09/409,305 

"specifying . . .attributes of a user ..." In contrast, the cited passage from Savitzky does not 
relate to, mention or even suggest user profile information or even a user. In particular such 
passage provides "[f]or example, if a new graphics document format, XYZ, were to be 
developed after an agency were in place, a new feature snippet IS_ XYZ could be sent to the 
resolver (possibly using a transaction directed at a "feature installer 11 agent) for insertion to 
feature calculator 21." (Savitzky, Col. 6, lines 55-60). Nowhere in this passage is there a 
mention or suggestion of user, user-profile, or even a profile in general. As such, Assignee 
contends that the Examiner has not met his burden of establishing a prima facie case of 
unpatentability. Further, claim 12 (pre and post entry of the present claim amendments) also 
provides that the "hierarchical relationships" between the attribute(s) are specified in the 
donut/hierarchical structure. Savitzky does not include this operation because features are stored 
in a features list, not a hierarchy. As such, there are no hierarchical relationships to specify in 
Savitzky. 

Similarly, with respect to claim 19, this claim depends from claim 12, as such, the 
arguments set forth above also apply to it. Further, this claim provides that the method includes 
"querying the user in order to obtain the user-profile information." There is no mention in 
Savitzky of querying a user. As such, Savitzky can not be read as teaching these additional 
elements. 

With respect to claim 21, this claim has been amended to depend from claim 19, which in 
turn depends from claim 12. For the foregoing reasons, Assignee contend that this claim is also 
not taught by Savitzky and is patentable over the prior art of record. 

With respect to claim 24, this claim provides that the user-profile information is used for 
selectively transmitting at least one survey question is to the user. Savitzky makes no reference, 
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mention or suggestion of sending survey questions to anyone, let alone to a user. As such, this 
claim is also patentable over the prior art of record. 

In paragraph 10 of the 4 th OA, the Examiner also relied upon Savitzky in rejecting claims 
4 and 14. Since these claims have been cancelled in the present response, in order to reduce the 
time and expense associated with prosecuting patent claims, Assignees note that this rejection is 
now rendered moot. 

In paragraph 1 1 of the 4 th OA, the Examiner has rejected claims 5, 6, and 15-16 because 
"Savitzky teaches chat rooms or services, col. 6, lines 65-66." Assignee again respectfully 
disagrees with the Examiner's characterization of Savitzky. Nowhere in col. 6, lines 65-66 (or 
elsewhere in the reference) does Savitzky teach, mention or suggest a chat room or service. In 
particular, this section of Savitzky provides "since agents each carry their own criteria, an agent 
programmed to act on or handle XYZ format documents can be easily installed into agency array 
20." An "agency array" is not a chat room. An agency array is a listing of agents and the type of 
features to which they respond. Therefore, Assignee respectfully requests the Examiner to more 
fully explain why and how he interprets an "agency array" to be equivalent to a "chat room of 
users." Absent such a description, Assignee contend claims 5,6, and 16 (claim 15 having been 
cancelled for purpose unrelated to patentability) are patentable over the prior art of record. 

In paragraph 12 of the 4 th OA, the Examiner has rejected claims 7 and 17 in view of 
Savitzky, col. 6, lines 57-59. Claim 17 has been cancelled for purposes unrelated to its 
patentability. Assignee contends that the portion of Savitzky relied upon by the Examiner does 
not teach a directory for routing content. Ironically, this passage from Savitzky is the same 
passage the Examiner relied upon previously in stating that Savitzky teaches a HAV of user- 
profile information, which Assignee respectfully traverses. Now, the Examiner contends that the 
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"features list" is also a directory. Yet, Savitzky does not mention user-profiles nor directories in 
the cited passage. As such, Assignee respectfully request the Examiner to explain how the cited 
passage from Savitzky teaches both a user-profile and a directory. Absent such an explanation, 
Assignee contends claim 7 is patentable over the prior art of record. 

With regards to paragraph 13 of the 4 th OA, the Examiner has rejected claims 8, 20, 23, 
26, 31, 37, 45, 54, 57, 58, 61-63, 66, 71, 72 75, 76, 94-95, 97, 11, 120, and 135 under Becker 
because "Becker teaches transmitting selected information, col. 5, lines 50-53." With respect to 
these claims, Assignee notes that claims 20, 23, 57, 58, 61-63, 66, 71, 72, 94-95, and 97 have 
been cancelled for purposes unrelated to patentability. Also, Assignee notes that each of these 
claims include elements and limitations previously discussed above with respect to the 103(a) 
rejections under Becker in view of Kramer and/or Becker in view of Savitzky, As such, 
Assignee contends that each of these claims is patentable over the prior art of record as being 
dependent from patentable independent claims. Assignee also contend that additional bases for 
patentability exist for many if not all of these claims, such additional bases are not necessary to 
set forth at this time in light of the above discussed distinctions, but, Assignee reserves the right 
to assert such further distinctions in the future, as necessary. 

In paragraph 14 of the 4 th OA, the Examiner has rejected claims 22, 29, 30, 35, 36, 38-43, 
47, 48-53, 55, 77-93, 96, 98-117, 119, 121-129, 133-134 and 139-141 because "Savitzky teaches 
monitoring the activities of a user, col. 1 1, lines 28-29." In regards to this passage from 
Savitzky, Assignee notes that the cited passage refers to an "interest agent" which "intercepts 
activity which indicates a user's interest." Further, the interest agent performs this interception 
by "scan[ning] the transaction to get a sense of what type of documents the user is retrieving and 
then independently obtains those documents ..." (Savitzky, col. 11, lines 64-67). As such, in 
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Savitzky the process of "indicating a user's interest" involves scanning the details of transactions 
and then providing documents that match such scanned details. There is no mention in Savitzky 
of user-profile information or updating user-profile information. Instead, Savitzky is geared 
towards monitoring transactions on a real-time basis and does not accommodate nor provide for 
creating a user-profile and or updates thereto. As such, one can appreciate that using Savitzky 
the level of filtering or matching of content to users is much less than that which uses currently 
updated user-profile information to determine content to provide to a particular user. Therefore, 
while Savitzky provides for the monitoring of transactional interests, it does not provide for 
updating user-profile information, as set forth presently pending claim 22. 

With regards to claims 29, 30, 35, 36, 38-43,47 - 53, 55, 77-93, 96, 98 - 117, 119, 121 - 
129, 133 - 134 and 139 - 141 Assignee notes that similar arguments to those set forth with 
respect to claim 22 may also be applicable. Assignee further notes that the scope of each of 
these claims may vary significantly from each other, as such, Assignee contends that the 
Examiner's rejection of these claims also fails to set forth a prima facie case of obviousness 
because the cited passage (Savitzky, col. 11, lines 28-29) clearly does not relate to the subject 
matter claimed in many of these claims. Therefore, for all of the preceding reasons Assignee 
contends each of these claims are patentable over the prior art of record and respectfully requests 
the Examiner to issue a notice of allowance for such claims. 

In paragraphs 15 - 18, the Examiner has responded to Assignees previous arguments as 
to why the subject matter of the presently pending claims is patentable over the prior art of 
record. Assignee contends the present claim amendments and remarks have answered the 
Examiner's questions as to the breadth and scope of the presently pending claims. Specifically, 
the present claim amendments have defined an hierarchical attribute value pair data structure to 
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be a structure in which at least one value pair (or attribute) is independent of the structure and is 
adapted for being shared with at least one other donut. Applicant contends that such a structure 
is definite and is novel and non-obvious. It is definite because an HAV does not cover any and 
every hierarchy - it covers those with at least one attribute that is independent of the structure 
and adapted for being shared. Since the Examiner has not shown any prior art references in 
which a hierarchical structure has an attribute (i.e., a value pair having a definition and a value) 
that is independent of the hierarchy, applicant contends the Examiner has failed to set forth a 
prima facie case of obviousness. Assignee respectfully requests the Examiner to issue a notice of 
allowance for each and every pending claim, after entry of the present claim amendments. 

Closing Remarks 

The Assignee thanks the Examiner for his review of the application and consideration of 
these remarks. The Assignee respectfully submits no new matter has been added by this 
response. Accordingly, and for at least the reasons given above, the Assignee respectfully 
submits all pending claims are in condition for allowance and solicits the issuance of a notice of 
allowance. 

This response is filed with a Petition for a two-month extension of time and associated 
fees. The Assignee believes no additional petitions or fees are required. However, should any 
additional Petitions or fees be associated with this response and required, please consider this a 
request therefore and authorization to charge Deposit Account 04-1415 as necessary. 
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In the event the Examiner has questions or comments and believes a telephone 
conversation would expedite a resolution, the Assignee invites the Examiner to contact the 
undersigned attorney at (303) 260-6362. 

Dated this SO day of September, 2003. 



Respectfully submitted, 




Registration No. 42,717 
Dorsey & Whitney LLP 
Customer No. 20686 
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